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(54) Providing secure access through network firewalls 



(57) To enable controlled, secure connections using 
a versatile protocol such as TCP/IP to be established 
through a firewall and proxy server, the versatile proto- 
col is tunnelled using HTTP. Client to server communi- 
cations are effected using an HTTP POST operation. 
Server to client communications are effected using an 
HTTP GET operation to establish a tunnelled socket; 



this socket is closed within an interval less than any 
timeout imposed by the proxy server and immediately 
re-established by another GET operation, irrespective 
of whether data continue to be pending for communica- 
tion to the client A globally-unique ID is included in each 
POST and GET message to enable related messages 
to be recognized. 
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Description 

Technical Field 



5 [00011 This invention relates to methods and apparatus for providing secure access between a service external to 
a network firewall (such as a web page server) and a client internal to the firewall (such as a web browser). 

Background Art 

10 [0002] Facilities for global access to information, such as the World Wide Web, are undergoing immense growth and 
expansion, both in volume of data transferred and in sophistication of tools, such as web browsers, foracceasing those 
data. This in turn requires the flexibility and capability of the data network infrastructure to be increased, without at the 

same time jeopardising its security features. Often these objectives conflict. 

[0003] Web based applications are "client-server" in nature. A client-based browser runs on an end user's computer, 

15 communicating via network links with a web server operated by a service provider. The server provides data defining 
the content of web pages which are rendered and displayed by the user's browser; typically the web page content is 
defined using a markup language such as Hypertext Markup Language (HTML). The commumcahons ' ^en the 
browser and the web server are conducted in accordance with a protocol called Hypertext Transfer Protocol (HTTP), 
defined in the Internet Engineering Task Force's RFC 1945. HTTP is a simple text-based protocol that has the peculiar 

20 quality that messages conforming to it are trusted and allowed to pass around the internets, intranets and extranete 
that make up today's "Internet". This Internet is really a series of closely coupled networks linked together trough 
"firewalls": network nodes that allow controlled, restricted access between two networks. However the ability to browse 
the world wide web" is seen as a universal common denominator, and as such HTTP messages are allowed to pass 
through these firewalls unchecked. There have been a number of enhancements to the HTTP protocol: the description 

25 herein relates by way of example to the basic version. HTTP/1 .0, which is supported universally and with which later 
versions of HTTP are backwards compatible. Nonetheless the invention is not limited to use with HTTP/1.0 or indeed 
any other specific version of HTTP, and the claims hereof should be construed accordingly. 

[0004] Web pages defined using the markup language can be enhanced by the use of code written in the Java 
programming language; this allows dynamic content and interactivity to be added to web pages. Java components can 
30 run either on the server end of the network connection, as "servlets", or on the client browser machine, in which case 
they are known as "applets". Many potential security problems were envisaged with the introduction of applets, such 
as "viruses" and "trojan horses", so a tight set of security restrictions were imposed on what applets could and could 
not do. To this end applets are executed on the client machine in a controlled environment called a "sandbox". This 
sandbox defines how the applet can interact with the resources available in the computational platform the applet is 
35 running on. viae limited application programming interface (API). For example, the applet typically cannot interact with 
the local disk, nor connect to other computers on the network in unrestricted fashion. However the applet can typically 
connect back to the web server it was served from, although by way of an HTTP connection only. References to Java 
herein relate by way of example to Java/1 . 1 which is widely deployed; later versions of Java provide enhanced network 
support, but are backwards compatible with this base version. 
40 [0005] The first generation of web content was mainly very static in nature - like pages from a magazine with text 
and pictures. The second generation of web content became increasingly dynamic, providing a user interface for ap- 
plications, such as database queries. The third generation of web content is becoming increasingly interactive, with 
real-time communications, such as video, text chat and Internet Telephony, being added as an integral part Internet- 
based client-server applications normally operate by opening "sockets" between the client and server, using Transac- 
ts tion Control Protocol/Internet Protocol (TCP/IP). TCP/IP sockets provide bi-directional, reliable communications paths. 
These can be used to implement dynamic or interactive client-server based applications, such as are required by the 
second and third generations of web content. 

[0006] However, these more sophisticated applications pose a problem, in that the communications protocols they 
often require for interaction with the web server, such as TCP/IP. are intentionally barred by firewalls and proxy servers. 
50 It is therefore an object of this invention to provide clients, such as Java applets in a sandbox, with some controlled 
ability (within the context of a specific web-based application) to interact through a firewall with other resources, such 
as web servers, using protocols in addition to HTTP. 
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Disclosure of Invention 

[0007] According to one aspect of this invention there is provided a method of permitting secure access between a 
service external to a network firewall and a client internal to the firewall, comprising the steps of: 
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ServerSocket class, to communicate with the client-based Java applet Messages between the Socket class and the 
ServerSocket class are carried within HTTP messages which traverse the firewall between the client and the server. 
[00161 The HTTP tunnel uses th underlying simple text-based HTTP protocol to produce a reliable connection- 
based protocol between the TunnelSocket and TunnelServerSocket classes. Basic HTTP transactions use one of two 

5 methods in the HTTP request message. The GET method is designed to "get" a web page from a web server and the 
POST method Is used to send data to a remote web resource or web application. In implementing the present invention, 
a GET based protocol is used for the client to server direction, and a POST based protocol is used for the reverse, 
server to client, direction, as shown in Figure 3. In the event that HTTP is supplanted by a functionally equ^alent 
protocol, it is envisaged that the invention could be used with operations in that protocol equivalent to the HTTP GET 

10 and POST operations. u . , 

[0017] A single connection between the TunnelSocket and TunnelServerSocket classes is likely to comprise multiple 
HTTP transactions. To associate these transactions together, a numeric Globally Unique ID (GUID) is generated using 
a combination of random numbers, networic address and time of day, so that each GUID generated is a unique quantity 
both in relation to time and location in the network. This GUID is incorporated in each HTTP request, both GET and 

is POST so that the HTTP protocol can recognize that they relate to the same communications socket Specifically, the 
GUID is passed as the HTTP Uniform Resource Indicator (URI) (the field used to specify a document name in normal 
use of HTTP). 

[0018] Client to server connection is implemented using the POST HTTP operation. Each time a write is performed 
to the client socket (TunnelSocket class) the request is packaged up and sent as the payioad of an HTTP POST 
20 message, including the relevant GUID, as shown in Figure 4. Each such write operation sends a separate POST 
message through the firewall. 

[0019] The server to client direction is more complex because of restrictions imposed by the proxy server 12 and 
the firewall 1 6. As shown in Figure 5, the client issues an HTTP GET message which tells the server that a new tunneled 
socket is being established. The HTTP GET request will generate a temporary server-client socket that allows data to 

25 be written from the server to the client. However as a security precaution most proxy server implementations will close 
down such a server-client socket after a time interval P, typically of the order often minutes in duration. Accordingly 
the tunnel established in this invention periodically itself forces a pre-emptive close down of the connection at some 
periodicity T which is shorter in duration than the interval P. This is accomplished by issuing another GET request, to 
force the TunnelServerSocket class to close the existing socket to the client and immediately establish a new socket. 

30 It should be noted that this closure (and subsequent reopening) are performed even though data are still pending to 
be transferred from the server to the client. This approach avoids the overhead of previous techniques, in which the 
client polls the server at some preselected polling interval, usually of the order of 20 milliseconds. These frequent polls 
are equivalent to multiple web page requests, so the server receives a large number of web hits per second, imposing 
a significant overhead and severely restricting the scalability of such prior techniques to handle large numbers of clients 

35 simultaneously. 

[0020] An illustration of the implementation of the invention is provided below, in the form of pseudo-code, which 
emphasizes the significant aspects of the implementation but for the sake of clarity omits minor details which, although 
required in practice, are well within the capability of a person skilled in the art Likewise the existence is assumed of 
certain subsidiary functions, such as guidFactory for creating a GUID and createFiFolnputStream for reserving and 
40 configuring memory for use as a first-in-first-out (FIFO) buffer; again these functions are individually well known in the 
art, so their internal details do not need to be specified. Depending on the particular manner of implementation, addi- 
tional parameters may be included, for example, in some function calls; this is indicated by an ellipsis (...). 
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1. Server to Client direction, 

la. TunnelSocket Im>utStr«>m Cade - runs on client 

5 

// 

// Open an Input Stream to the Server 

// This is the Server to Client direction of the Tunnel Socket. 

10 // eerverAdresss - Internet address e.g. fred.hpl .hp.conu 

// standard socket 

// Port number is a port number on the server machine to 
// connect to: standard socket 
15 public open (server Address , portaumber) { 

// Generate a new Globally unique id for the new socket. 
// The id is unique across the whole network and across 
// time. 

20 // It is generated using a random number generator, the 

// node's network address and the current time, 
guid m guidXactoryO i 

// Create a Pifo stream that is used by the application code 
25 //to read data. 

// The underlying protocol reads data off the wire into this 

// Pifo ready for the application. 

f ifoXnputstream - createFif ©Inputs treamO » 

30 II Issue an HTTP/ 1.0 GET request to the server 

// The on -the -wire format is: 
// GET <guid>? commandoes tablish 
// Content -Type-application/octet -stream 
35 InputStream - issueBttpGetftequaat (uri-gttid, 

qneryatring» m cossmand establish" , 
Content -Type»»application/octet- stream" , 
address*serverAddress, port-port) % 

40 II Start a timer thread that is invoked at a periodicity of 

// GBTTimeOut seconds. 

// Typically GBTTimeOut is a few minutes in duration - but 
// it must be less than the time out period of the proxy. 
// The function switchGBTStreamO is called at the 
45 if periodicity with its own thread of execution. 

• tartPeriodicTimeCmtDe»on(awitchaiTStreaa() , GBTTimeOut) i 
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II Send a new request to the server telling it to close down 
// the current stream and establish a new stream 
// periodically 
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private switchOTT8tream() { 

// Lock the Input Stream t prevent any race conditions with 
// readlnputStream 
look ( input StreamLock) 

aewXnputStreem m iasueBttpOetBequeat(uri«guid, 
queryflt r ing« m c i a— i id ■ swt ten* , 
Content -Type- m appXication/octet-»treaaf , 

address«serverAddress, port -port) i 

// Drain the contents of the stream until it is closed by 
// the remote end 

while (read ( Inputs treaa, PlfoStreaa) I- «OF) j 
writeToFifo(FifoXnputStream) i 



input Stream » nawXnpu tStream ( ) t 
unlock ( inputs treaa&ock) t 

return () ; 



// Read data from the stream via the Pifo - the Pifo buffers 
// data up ready to be read 
public readlnputStream ( . . . , but, lea) { 

// if there isn't enough data in the Pifo to satisfy this 
// read request - top it up from the wire, 
if (IFifoStream. length <> > lea) { 



35 //Transfer data from the stream established to the Server 

lock(inrmtStreemLock) % 

writeToPifo<FifoXnput8treaa, read { Inputs cream, 

lea - FlfoStream.lengthO) % 
unlock ( inputs traaalfock) t 

40 ) 

// return data in from Pifo 

return (read (FifolnputStreaa, ...» buf, lea) ) ) i 

45 v 



50 " 

public close <) { 



// Stop timer thread 

« topPariodicTiaeOutDmou ( twi tahGSTS tream ( ) ) t 
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// Hark stream as cl eed 
marklxxputStraasClOBedO t 
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lb. TunnelServerSocket OutoutStream - nms on the server 

// Server side Protocol engine handling all requests the server receives 

// Sit waiting on a ServerSocket for socket connections to come 
// in - just standard socket call 
while ((socket ■ accept () still open) { 

httpheader - readHttpHeader (socket) t 

if ( httpHaadar.type — ~OBT" afc 
httpHeader. cosmuuid - establish) { 

// New socket request 

// Open an output Stream 

outputs traam - socket. getOutputStream( ) j 

// Add an entry to the database of opened Tunnel Sockets 
addSntryTunnelSoeketHashDataBase (socket* outputstream, 
httpHeader . gold) i 



} else ( httpHaadar.type « W 66 
httpHeader. command * •witch-) { 

// Lookup tunnel Socket 
tunnelSocket ■ 

lookupKntryTunnelSooketOatabase(httpBeader.gttid) t 

// Request to switch stream generated by the TunnelSocket 

// timer on the client 

// Close the current output stream 

// Take lock to avoid conflict with 

// tunnelOutputStreamVfrite 

lock ( tunnelSocket • outputs treamLock) > 

close (tunnelSocket .outputs trees) j 

// establish a new output stream on this new connection. 
tunnelSocket. outputs tream - socket. getOutputStreamO i 
unlock ( tunnelSocket . outputs treamLock) 
} else (httpheader. type — "POST- ) 

// See pseudo-code fragment included below with Server - 
// Client direction. 
doPOSTO i 

} 

tunnelOutputStreamWrite (buf , len) { 

// Take lock to avoid conflict with "switch' in 
// tunnel Serve rAccept ( ) 
lock ( outputs treamltock) 
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writs (output Stream, buf , Imn) i 
unl ck (outputs treaaLocfc) 
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2. Client-Server direction. 

2a, Client side TunnelSocket OutoutStream 
public write (buf, length, . ..) { 

// Issue an HTTP/1.0 POST request to the server 
// The on the wire format is: 
// POST <guid> 

// content -Type-application/octet -stream 
/ / Content -Length- < lengt h> 

inputStreaa - iMuaHttpPOSTRequeat (uri-guid, 
Content -Length- length , 

Content-Type- m application/octet-strea»*# 
address BftrorAddxiu, port-port, payload-bu£) i 

} 



2b. Server side TunnelServcrSocket InputStream 
public readServerSideInputStreaa(buf , lan, . ..) { 

return (r«adTro»Pi£o (TifoServerSidelnput Stream, but, len, 

} 



// On receiving a POST request (see lb above) 

// copy the pay load into the Pifo buffer ready for the 

// readServerSidelnputStream to read it. 

doPOSTO { 

writeToPif o (Fif oServerSidelnputStrean, 

h t tpRequee t . readPayLoad ( ) , h t tpBeeder - con ten tLeng th) i 

) 



Claims 

1. A method of permitting secure access between a service externa! to a network firewall and a client internal to the 
firewall, comprising the steps of: 
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- (a) effecting an HTTP GET operation or equivalent thereof from the client to establish a communications socket 
for communicating data from the service to the client; 

- (b) after a predetermined interval effecting another GET operation or equivalent thereof to close the commu- 
nications sock t, irrespective of whether access between the service and the client is required to continue; and 

. repeating steps (a) and (b) while access between the service and the client is required to continue. 

2. The method of claim 1 . wherein the predetermined interval is less than another interval after which client software 
enforces termination of a communications socket established by a GET operation or equivalent thereof. 

3. The method of claim 1 or claim 2, wherein information is transferred from the client to the service by an HTTP 
POST operation or equivalent thereof. 

4. The method of any one of the preceding claims, wherein successive messages transferred between the client and 
the service are identified by a globally-unique identification created by the client and communicated to the service. 

5. The method of claim 4, wherein the globally-unique identification is communicated via an HTTP GET or POST 
operation or equivalent thereof. 

6. The method of claim 5, wherein the globally-unique identification is communicated in a URI relative path compo- 
nent 

7. The method of any one of the preceding claims, wherein communications with the client traverse a proxy service 
located on the client side of the firewall. 
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